Many computer systems, a decade ago, employed hardware on which an operating system was installed to enable software applications to be run on the hardware. FIG. 1A illustrates such a simple configuration of hardware and software. More recently, however, businesses, governments, universities and others are taking advantage of large scale networks, including intranets and the internet, to allow users located virtually anywhere to easily access applications running on machines which are also located virtually anywhere. Thus, as illustrated in FIG. 1B, additional layers are required for a user at a browser client to ultimately (but transparently) access data through server-based applications. More importantly, such enterprise computing permits combining different, often incompatible, operating systems, applications and user interfaces into the same network.
Large applications, such as application servers, may include hundreds or more individual components to install, each of which may include numerous sub-components. One example is the IBM® WebSphere® Application Server (“WAS”). In addition to the directories and files which comprise WAS, as illustrated in FIG. 2 WAS 200 also operates in conjunction with an object-oriented data base, such as IBM's DB2®-UDB 202, and an HTTP server, such as IBM's HTTP Server 204. Each of these applications comprises many components and sub-components 206. Moreover, enterprise software is frequently deployed or installed in a cluster or group of machines. Thus, when the WAS Enterprise edition is deployed, components 206 of each of the three major components (WAS 200, DB2 202 and HTTP Server 204) are installed on many machines in order to achieve a satisfactory load balancing. Heretofore, such a deployment has been a labor intensive, time consuming and error prone activity by a system administrator installing many components across many machines in a domain. And, unfortunately, heretofore, such a deployment involves installing the files sequentially, thereby adding to the time required.
An additional issue is raised due to the almost infinite number of combinations of software settings and configurations on multiple hosts with multiple parameters. Such complexity makes it extremely difficult for an administrator to devise reliable test plans to insure the validity of change to software within an enterprise. Thus, seemingly harmless upgrades, patches, or new software may wreak havoc on an enterprise infrastructure. Existing software may unintentionally be compromised or corrupted by additional software or software updates. It will be appreciated that such unforeseen consequences may cause part or even all of a business's enterprise system to fail. For example, a new JAVA Software Development Kit (SDK) is deployed each time an application, which uses JAVA is deployed. Although the JAVA SDKs are supposed to be back-compatible they are not. Furthermore, developers commonly use both SUN and IBM JAVA SDKs, introducing a number of incompatibilities. That is, JAVA applications which were functional under SUN JAVA version 1.3.1, for example, might not work properly under Sun JAVA 1.4.1 or IBM JAVA 1.3.1.
The JAVA SDK incompatibilities described above present one of the more common problems in JAVA 2 Platform Enterprise Edition (J2EE) environments. However, although very harmful, this is a relatively simple problem to detect. More complicated problems are presented at the operating system (OS) and compiler levels. Frequently at the OS level there may be incompatibilities between different versions of an OS kernel and certain applications. For instance, IBM JAVA SDK version 1.4.1 runs only with a LINUX kernel 2.2.5 or less, while the current LINUX kernel on RED HAT LINUX is 2.5. Thus a new deployment will likely update the kernel and consequently perturb the functionality of the JAVA Virtual Machine (JVM) and consequently all applications that use the JVM. A similar problem might occur with OS patches.
More subtle problems may exist at the compiler level. Although different compilers use different optimization techniques, many developers are unaware of these techniques and the differences. Thus, a syntactically correct code may run differently on two compilers. For example, IBM employs the Just in Time Compilation technique (JIT) which provides an advanced optimization for the JAVA code. Assume that certain code reads the time, then performs some computation and finally reads the time again. When an IBM compiler is used, the time difference between the two readings will be zero, because the compiler sees no dependency between the computation and the first time reading and thus will first execute the computation. In contrast, the same piece of code will run as intended using a SUN interpreter.
Un-installation of software poses a somewhat similar problem. There are large software applications which use services from other components. For instance, WAS uses the DB2-UDB and the IBM HTTP Server. If the users decide to un-install either of the latter, WAS will no longer function. Such dependencies extend from the very high level, such as the WAS/DB2-UDB/HTTP Server example, to the finer component level, such as libraries and jar files.
While some enterprise software includes the ability to “roll back” software changes, upgrades or installations, not all enterprise software includes this function. Consequently, the responsibility to identify negative repercussions and account for a multitude of configuration scenarios rests with the software developer. It will be appreciated that developers are increasingly unable to anticipate all potential problems as software scales into enterprises and enterprises themselves increase in scale.
Still further issues arise during an installation/deployment of enterprise applications. Various people involved in installing applications and supervising their installation have differing needs during the process. For example, while a supervisor may only need a high level summary of progress, an installation administrator should be able to access detailed information on a continuous basis. However, in a large enterprise deployment, there may be an overwhelming amount of installation information available. As noted above, there may be as many as 1000 or more different components being installed. Currently, all of the information may be written to a log file, as illustrated in FIG. 3, leaving the user to decipher the contents and identify failures or other problems. Alternatively, a custom program may be written to show the progress of the installation. Such a program generally includes hard coded scripts which take time to write and must be rewritten when additional components are added. Although existing install scripts may present some screens which reflect the overall progress of installation or which provide information about the feature of the application being installed, these screens do not reflect the status of the installation of the actual components. Coupled with the long period required by the installation process, the user is left with little or no information of the actual component progress and very often has to check the functions of the underlying operating system in order to determine progress or even confirm that the installer hasn't stalled but is still proceeding.
Thus, there remains a need for a more efficient installation process.